Module 2: Single to Multiple Accounts

🏗️ Why Multiple Accounts?

🔒 Security Isolation

Blast radius containment — compromise in dev doesn't affect prod

💰 Cost Allocation

Per-account billing, chargeback to business units

📏 Service Limits

Each account has independent quotas — avoid throttling

🏛️ Governance

Separate compliance boundaries (PCI, HIPAA, FedRAMP)

Analogy: Multiple accounts are like apartments in a building — shared infrastructure (the building/Organization), but each tenant has their own locks, utilities meter, and space.

🏢 AWS Organizations

Management Account: Root of the org — owns consolidated billing, creates OUs
Organizational Units (OUs): Logical groupings (e.g., Prod, Dev, Security, Sandbox)
Member Accounts: Workload accounts within OUs
Consolidated Billing: Single payer, volume discounts apply across all accounts
All Features Mode: Enables SCPs, tag policies, backup policies, AI opt-out policies

Best practice: Never run workloads in the management account. It should only contain Organizations administration and billing.

🛡️ Service Control Policies (SCPs)

Aspect	SCP Behavior
Type	Permissions guardrails (deny or allow lists)
Applies to	All IAM principals in member accounts (not management account)
Effect	Sets maximum available permissions (does NOT grant permissions)
Inheritance	Applied at OU level, inherited by child OUs and accounts
Deny strategy	Explicit Deny in SCP overrides any Allow in IAM policies

Key concept: SCPs are like building codes — they set the boundaries of what's possible, but you still need to grant specific permissions via IAM policies. SCP Allow ∩ IAM Allow = Effective permissions.

🆕 Resource Control Policies (RCPs)NEW

What: Organization-wide policies that control access TO resources (resource-based perspective)
How: Applied at OU/account level — restrict who can access resources regardless of IAM policies
Use case: Prevent external principals from accessing S3 buckets, even if bucket policy allows it
Complement SCPs: SCPs control what principals CAN DO, RCPs control WHO can access resources

New in 2025: Resource Control Policies are a new policy type in Organizations. They work alongside SCPs to provide defense-in-depth. RCPs are evaluated before resource-based policies.

🏰 AWS Control Tower

Purpose: Automated landing zone setup with governance built-in
Landing Zone: Pre-configured multi-account environment (audit, log archive, shared services)
Controls (Guardrails): Preventive (SCPs), Detective (Config rules), Proactive (CloudFormation hooks)
Account Factory: Self-service account provisioning with pre-approved configurations
Dashboard: Compliance status across all enrolled accounts

Update (2025): Control Tower LZ 4.0 introduces "Controls-Only" experience — 750+ managed controls without full Control Tower deployment. Accounts auto-enroll when moved to an OU.

🔄 Cross-Account Access Patterns

Pattern	Mechanism	Use Case
IAM Role Assumption	sts:AssumeRole with trust policy	Admin access to member accounts
Resource-Based Policy	Principal ARN in resource policy	Cross-account S3, KMS, SNS access
AWS RAM	Resource Access Manager sharing	Share subnets, Transit Gateways, resolvers
Organizations Trust	org-id or OU conditions	Org-wide access to shared services

Best practice: Use aws:PrincipalOrgID condition in resource policies to restrict access to your organization, preventing external account access even if someone knows your resource ARN.

💻 Demo: Organizations & SCPs

# List accounts in the organization
aws organizations list-accounts --query 'Accounts[].{Id:Id,Name:Name,Status:Status}'

# List OUs under root
aws organizations list-roots --query 'Roots[0].Id' --output text
aws organizations list-organizational-units-for-parent --parent-id r-xxxx

# List SCPs attached to an OU
aws organizations list-policies-for-target --target-id ou-xxxx --filter SERVICE_CONTROL_POLICY

# Describe a specific SCP
aws organizations describe-policy --policy-id p-xxxx

🏗️ Control Tower Landing Zone — Components

Analogy: Building a Corporate Office — A Landing Zone is like constructing a corporate headquarters before employees move in. You set up the building (accounts), security systems (guardrails), elevators between floors (networking), a mailroom (logging), and access cards (permissions) — all standardized before anyone starts work.

🏢 Management Account

Analogy: The CEO's office — oversees everything but never does the actual work. Only used for billing and Organization management. Never deploy workloads here.

🗂️ Organizational Units (OUs)

Analogy: Floors in the building — Dev floor, Prod floor, Security floor. Group accounts by purpose. Policies apply to entire floors.

🔒 Guardrails (Controls)

Analogy: Building safety codes — fire exits must exist (mandatory), some floors can't have kitchens (preventive), and smoke detectors alert security (detective). 750+ managed controls available.

🏭 Account Factory

Analogy: A cookie cutter for new offices — every new account gets the same setup: VPC, IAM roles, logging, security baseline. Consistent, repeatable, fast.

📋 Log Archive Account

Analogy: The building's CCTV control room — all CloudTrail logs, Config records, and audit trails flow here. Immutable, centralized, nobody can tamper with the recordings.

🛡️ Audit (Security) Account

Analogy: The security guard booth — cross-account read access to all accounts for security team. Security Hub, GuardDuty findings aggregate here. The watchtower.

🌐 Network Account (Shared)

Analogy: The building's utility room — Transit Gateway, Direct Connect, DNS all live here. Shared via RAM. Other accounts connect but don't manage networking.

📐 Baseline (Config/Remediation)

Analogy: Building inspections — AWS Config rules continuously check compliance. Auto-remediation fixes violations. Like having automated building inspectors that also fix issues.

🧪 Knowledge Check

Q1: An SCP with an explicit Deny on s3:DeleteBucket is attached to a Production OU. A user in a prod account has an IAM policy with Allow on s3:*. Can they delete a bucket?

A) Yes, IAM Allow overrides B) No, SCP Deny wins C) Depends on resource policy D) Only in management account

B) No, SCP Deny wins — An explicit Deny in an SCP always overrides any Allow in IAM policies. SCPs set the maximum permissions boundary.

Q2: What is the key difference between SCPs and Resource Control Policies (RCPs)?

A) SCPs are preventive, RCPs are detective B) SCPs control what principals can do, RCPs control who can access resources C) RCPs replace SCPs D) SCPs apply to resources, RCPs apply to users

B) SCPs control what principals can do, RCPs control who can access resources — SCPs are principal-centric (restrict actions). RCPs are resource-centric (restrict access to resources regardless of who's asking).

📝 Module 2 Summary

Organizations

Management account + OUs + member accounts. Consolidated billing. Never run workloads in mgmt account.

SCPs & RCPs

SCPs = max permissions boundary for principals. RCPs = resource access controls. Both are guardrails, not grants.

Control Tower

Automated landing zone. Account Factory. 750+ managed controls. Auto-enrollment (2025).

Cross-Account

AssumeRole, resource policies, RAM sharing. Use PrincipalOrgID conditions for org-scoped trust.